-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: mise en cache en environnement de developpement #862
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
À mon avis, il serait préférable d’utiliser le même backend en test/dev et en prod pour réduire les différences entre les environnements, qui sont toujours une source de bugs.
Je vois de nouvelles requêtes de la forme suivante :
Je pense que les requêtes supplémentaires sont correctement capturées. Je vois que la CI lance compress. Comme les requêtes supplémentaires viennent de django-compressor, je pense qu’il y a un bon suspect. |
Je comprends parfaitement ton argument @francoisfreitag concernant le fait d'avoir des environnements les plus similaires possibles (d'autant que tu m'en as déjà parlé ;) ) L'autre option est une fixture limitée à la fonction, qui force la compression à chaque test.
Les tests redeviennent passant, bien que sensiblement ralentis. Qu'en penses-tu ? |
d80bec7
to
31f5947
Compare
J’ai poussé un commit qui devrait te plaire :) |
je te confirme que ça me plait beaucoup ! en local, suite complète de tests en 1 min 54 contre 3min 15 quand la fixture a un scope |
eda505e
to
9ac9830
Compare
🐗 problème rencontré
CI
🦺
DatabaseCache
=> tests okpytest local :
🦺
DatabaseCache
=> tests KO 🧧🦺
DummyCache
ouLocMemCache
=> tests OK 🍏🦺 avec les settings de
config.settings.base
+COMPRESS_OFFLINE=False
=> tests KO 🧧🦄 solution
Type de changement
🪲 Correction de bug (changement non cassant qui corrige un problème).
🚧 technique